A continuation-based runtime operates by scheduling work items. Work items can be associated with a callback identifying where a procedure or activity is to be resumed. An activity represents a unit of executable code comprising multiple pulses of work. Unlike conventional computer software programs that sequentially process data, a continuation-based program communicates by registering continuations and scheduling activities as future work to perform tasks. By manipulating the scheduling of future work and child activities, a higher-level composite activity can define arbitrary control-flow constructs.
A continuation-based runtime has advantages over sequential computer software programs, such as facilitating passivation by which an activity can be persisted and resumed in a different process/thread, including on an entirely different machine.
A data model may be used in a continuation-based runtime to define data flow direction with respect to activities via parameters and to provide for data storing and sharing between activities via variables that are based on a tree relationship between activities. An activity tree includes a topmost parent composite activity and at least one child activity of that topmost parent composite activity. Variables are associated with one or more composite activities of the tree; for example, arguments such as binding expressions may bind variables to an activity's parameters.
When processing the activities of an activity tree in a continuation-based runtime, parameters represent a flow of data relative to that activity, by declaring each parameter as an input parameter, an output parameter, or an input-output parameter. Variables are declared to represent the storage of data. Scoping provides that a child activity may access variables up its parent chain. Binding expressions may be used to bind a parameter to in-scope variables.
A program definition in a continuation-based runtime may be modularized, such that modules of the program can be edited independently. These modules may be reused within the same program or in different programs. Existing systems for dynamic update do not support automatic updating when the contract of a module changes.